找到軟體缺陷是品質保證人員的責任嗎？

一般使用瀑布式開發的軟體開發公司，當程式人員開發完軟體後，下一個階段就是測試階段。

瀑布專案的日常

在測試階段的時候， QA 人員(Quality Assurance:品質保證，俗稱測試人員)就會開始他們的工作。

他們會拿著事先定義好的測試文件開始一條條檢測，這是相當花費人力的工作。不單單只有這次的新功能要測試，以前的舊功能也要測試確保他們沒有問題。所以可想而知，隨著時間的演進，他們每次進行測試的量就會變多，時間也會越來越久。

專案進入測試需要等三個月

如果你的公司有很多開發團隊，這些開發團隊開發出來的軟體都要送給測試團隊進行測試，很可能當你的軟體開發好以後，測試團隊跟你說需要排到三個月後再進行測試。

這時你的團隊就會去開發下一個產品，等三個月後 QA 給你一份 Bug 清單，你再回來開始修改。

修改完後再進行測試。這樣大概進行三個回合後，你的軟體 Bug 數量應該就會非常少，進入一個可接受的範圍。

最後在由各各大頭討論一下目前的 Bug ，大家都同意這樣可以發佈後，你的軟體就可以發佈了。這樣一個流程下來，從開發好到可以發佈大約是半年的時間。

當然在敏捷開發裡，我們會解決這樣的問題，我們後面再來談。

有興趣的人可以先參考之前的文章裡所提到的概念

• 比較優勢原理
• 團隊中大家一起努力完成工作
• 團隊中每個人都做擅長的事
• 敏捷想要追求的是什麼

讓 QA 找不出軟體缺陷

這裡我們先把焦點放在專業的軟體開發人員上面。昨天我們說過你應該要對你的不完美負責，所以在你的軟體交付 QA 時你應該確保他們找不到任何問題。

故意發送明知有缺陷的程式那是極其不專業的表現，那些你沒有把握的程式碼都是會有缺陷的。

有些人會把 QA 當成專門抓 Bug 的來看待，所以他們把自己沒有完全檢查過的程式碼送給 QA， 想等 QA 把問題找出來後再來修改。

說好聽一點這叫分工合作，但把自己沒有把握的軟體送給 QA 這就是不專業的表現了。

還是有 Bug 怎麼辦？

如果你已經做了完整的檢查， QA 還是發現了 Bug 怎麼辦？

還記得專業人士要練習的第一件事情就是道歉嗎？ 道歉完後，反思一下這些 Bug 是如何逃過你的法眼的，然後想辦法防止它們再次出現。這些都是你的學習和成長。